The communications industry is rapidly changing to adjust to emerging technologies and ever increasing customer demand. This customer demand for new applications and increased performance of existing applications is driving communications network and system providers to employ networks and systems having greater speed and capacity (e.g., greater bandwidth). In trying to achieve these goals, a common approach taken by many communications providers is to use packet switching technology. Increasingly, public and private communications networks are being built and expanded using various packet technologies, such as Internet Protocol (IP).
A flow is a set of packets passing through a network during a certain time interval that possess some common properties. Identification of which packets belonging which flows is necessary in a data network. Nodes within the data network can then select packets based on this identification and perform operations that are defined by the user. For example, all packets originating from Autonomous System (AS) 10 and destined to AS 20 can constitute a flow. Billing based on network traffic between AS 10 and 20 can be done by counting all the packets and bytes that belong to this flow.
Today, there is no one consistent way to define flows that work across applications, such as, but not limited to quality of service, billing, access control, routing, statistics, network management, or any other process or operation performed which requires information pertaining to one or more flows. One known way of identifying flows and corresponding packets is to define a super-flow comprising of all the possible property fields on which a match is possible. The fields of interest get filled in with values to be matched and the rest are wild-carded (i.e., set to a don't care conditions so these fields match every value/packet). However, this scheme uses a lot of valuable resources (e.g., associative memory entries), and very often not all of these fields are required for identifying packets belonging to a flow for a given application.
For example, the super-flow for IPV4 is defined as the tuple {source IP, destination IP, source port, destination port, L3 protocol, TOS, TCP flags}. An application like customer prefix based billing, requires only {destination IP Prefix, mask length, TOS}. Using IPV4 super-flow for this application leads to an overly complicated configuration task for the user. Applications come up with requirements to add new fields to define more detailed flows. This affects all applications whether they intend to use these new fields or not. This may result in incompatibility with previous super-flow configurations.
Another known way of identifying flows and corresponding packets is to provide a fixed set of predefined types of flows, such that applications can select among these flow types. Such predefined types are not flexible nor customizable, and may not meet the requirements of an application or customer. Moreover, as the demands of existing and new customers change, so does the desired flow types, and to add new predefined flow types requires significant development costs and deployment delays.
Needed are new methods and apparatus for defining flows and identifying packets corresponding to the defined flows.